【書評】オブザーバビリティ・エンジニアリング

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

クラウドベースのシステムを開発・設計・運用する方々へお勧めしたい書籍を紹介します。
オブサーバビリティの概念が広まって久しいですが、正解が無いこの概念の実装でお困りの方は多いと想像してます。そのような方々の参考になる書籍だと思います。

書籍情報

オブザーバビリティ・エンジニアリング
Charity Majors、Liz Fong-Jones、George Miranda　著、大谷 和紀、山口 能迪　訳

オライリー・ジャパン社のサイトから引用した本書の概要です。

本書は、近年のクラウドベースのソフトウェアシステム開発における設計プラクティスなどにおいて触れられる概念「オブザーバビリティ（可観測性）」に関する書籍です。オブザーバビリティとは何か、どのように役立てるのかなど、登場の背景から実践方法、組織、企業への適用といった幅広い視点で解説します。今後、ソフトウェアシステムの開発においてオブザーバビリティが果たすであろう、より大きな役割についても触れています。さらにSlackのゲスト寄稿者により、テストとデプロイプロセスへのオブザーバビリティの適用と、パイプラインによるテレメトリー管理についてのケーススタディを紹介。本書はソフトウェアに関わる多くの人々にとって今後より一般化するオブザーバビリティを知る第一歩となるでしょう。

目次

第Ⅰ部　オブザーバビリティへの道

1章　オブザーバビリティとは？
2章　オブザーバビリティとモニタリングにおけるデバッグ方法の違い
3章　オブザーバビリティを用いないスケーリングからの教訓
4章　オブザーバビリティとDevOps、SRE、クラウドネイティブとの関連性

第Ⅱ部　オブザーバビリティの基礎

5章　構造化イベントはオブザーバビリティの構成要素である
6章　イベントをトレースにつなぐ
7章　OpenTelemetryを使った計装
8章　オブザーバビリティを実現するためのイベント解析
9章　オブザーバビリティとモニタリングの関係

第Ⅲ部　チームのためのオブザーバビリティ

10章　オブザーバビリティへの取り組みをチームへ適用する
11章　オブザーバビリティ駆動開発
12章　サービスレベル目標の信頼性向上への活用
13章　SLOベースのアラートへの対応とデバッグ
14章　オブザーバビリティとソフトウェアサプライチェーン

第Ⅳ部　大規模なオブザーバビリティ

15章　投資収益性: 作るか、それとも買うか
16章　効率的なデータストア
17章　安価で十分な精度にするためのサンプリング戦略
18章　パイプラインによるテレメトリー管理

第Ⅴ部　オブザーバビリティの文化を拡大する

19章　オブザーバビリティのビジネス事例
20章　オブザーバビリティの利害関係者と協力者
21章　オブザーバビリティ成熟度モデル
22章　ここからどこへ

第Ⅰ部　オブザーバビリティへの道

第Ⅰ部はオブザーバビリティの定義を解説しています。現代のシステムにおいてオブザーバビリティがなぜ適しているかを学べます。

ソフトウェアアプリケーションにオブザーバビリティを持たせるための要件は以下と示されています。

• アプリケーションの内部構造を理解する
• 予測できないことが起こったとしても、どのような状態に陥っているか理解する
• 外部ツールを使って観測・調査し、内部動作と状態を理解する
• コードを改修することなく、内部情報を理解する

何が起きているか理解できるようにすることが、オブザーバビリティの真意であると読み取っても過言ではないと感じました。

モニタリングとの違い

それでは、オブザーバビリティとモニタリングの違いは何でしょうか？

	オブザーバビリティ	モニタリング
調査	問題がどこでなぜ発生しているか反復探索的な調査が可能	システムの状態を既知のしきい値と照合
アプローチ	既知・未知に関らず、積極的なアプローチ	リアクティブなアプローチ
最高のデバッガー	最も好奇心が高いエンジニア	組織に長くいる者
隠れた問題の発見に対して	正しい答えを導き出すためにデータを追う	本当の問題が見えにくい、症状の緩和をまずしてしまう
ツール間や被疑箇所間の相関	明確なデータになっており、どのエンジニアでも探索可能	固有の非互換や矛盾が発生し、相関を導き出すことに苦労
障害領域の予測	分散トレースや複数のシグナルを組み合わせて俯瞰	粗いレベルのメトリクスと閃きを組み合わせる

(吉井)従来のモニタリングを否定するものではなく、システムの複雑さや規模が増していくことでモニタリングの限界が現れ始め、オブザーバビリティという新しいアプローチが誕生したものと理解しました。 クラウドネイティブによってもたらされる新しい運用コストが、従来の運用作業習慣では処理できないと気付いた結果が、オブザーバビリティだとも言えます。

第Ⅱ部　オブザーバビリティの基礎

第Ⅱ部は、技術的な側面からオブザーバビリティの必要性を解説しています。

• 構造化イベントを使う
  • システムがどのような状態にあっても、あらゆる質問に答え、データを任意かつ詳細に繰り返し分析でき、完全な抽象度で収集するため
• 構成要素としてのメトリクスの限界
  • メトリクスは事前に集計された測定値
  • あるサービスへの1つのリクエストは、複数のメトリクスで表現される可能性がある
• 構成要素としての従来のログの限界
  • 非構造化ログは人間には読みやすい、機械が解析することは難しい
  • 現在のシステムは人間が解析できるスケールではない
  • 構造化ログを作成する
• 分散トレースとその重要性
  • 相互に関連した一連のイベント
  • システムの相互関係を理解するのに役立つ

OpenTelemetry を使った計装

OpenTelemetry はトレース、ログ、メトリクスなどのテレメトリーデータを好みのバックエンドへ送信可能で、オープンソース標準です。

OpenTelemetry は自動計装が用意されており、エンジニアの負担を減らしながら短時間でテレメトリーデータの収集が計装可能です。
自動計装で基本的なテレメトリーデータを収集しつつ、ビジネスロジックに特化したカスタム計装を取り入れます。

イベント解析

仮説駆動形デバッグ (仮説を立てて、それを確認するためにデータを探索する手法)は、デバッグという行為を民主化します。

(吉井) いい言葉です。オブザーバビリティによって ”生き字引エンジニア” の頼らないデバッグが手に入ります。 問題をデバッグする際に、事前にそれほど多くのことを知る必要がない、これこそがオブザーバビリティの本当の威力だと解説されています。 その考え方の実践は書籍に書かれていますのでぜひ読んでみてください。

オブザーバビリティとモニタリングの関係

従来のモニタリングをすべて捨てることは大胆で軽率です。
オブザーバビリティとモニタリング、それぞれに適した場所があります。

• モニタリングが適した場所
  • 既知の未知を検出
  • 既知の障害に反応して、人間に通知する
  • 変化の範囲が予測可能
  • システムの健全性を評価
• オブザーバビリティが適した場所
  • 未知の未知を発見
  • アプリケーションレベルの問題を理解するのに最適
  • 多数の新機能がデプロイされる
  • ソフトウェアの健全性を評価

第Ⅲ部　チームのためのオブザーバビリティ

第Ⅲ部は、オブザーバビリティの採用を促進するための社会的、文化的な慣習の変化についてです。

チームへの適用

もっとも難しいのはオブザーバビリティのチームへの適用です。適用アプローチはどのような方法であっても間違いではありません。 以下のヒントを参考にします。

• コミュニティグループに参加する
• 最大の問題点から始める
  • スモールスタートの逆
• オブザーバビリティツールは作るより既存を採用する
• 計装を繰り返し完成させる
• 旧来ソリューションのサンクコストにとらわれない
• 再利用できるよう出来るだけ汎用化する

開発サイクルにおけるオブザーバビリティ

バグを迅速に解決するには、原作者(プログラマ)の頭の中に新鮮な意思が残っているうちに問題を検証できるか、に依存しています。

オブザーバビリティを、デバッグが必要なコードがどこにあるかを見つけ出すもの、として利用します。

オブザーバビリティをシフトレフトし、本番環境に与える影響を迅速に検討・確認できるようにします。

SLO と一緒に実践

SLO のアラートはユーザー体験に影響を与える症状のみを考慮します。また、そのアラートはアクション可能でなければなりません。
SLO ベースのアラートは症状を教えてくれます。オブザーバビリティによって本番環境で安全なデバッグが可能になります。

• SLO ベースのアラート => なに
• オブザーバビリティ => なぜ

オブザーバビリティとソフトウェアサプライチェーン

CI ワークフローが50万回を超えてくると、開発環境のコードテストやデプロイが一部の本番サービスより複雑になります。
ソフトウェアのサプライチェーンにオブザーバビリティが必要なことに気が付きました。

(吉井) 14章は Slack 社による寄稿となっており、ソフトウェアサプライチェーンの問題に対してオブザーバビリティがどのようの役立ったのかが細かく書かれています。興味のある方は書籍をお読みください。

第Ⅳ部　大規模なオブザーバビリティ

第Ⅳ部は、オブザーバビリティの採用が成功し、大規模に実践された場合の話です。

買うか作るか

オブザーバビリティを導入する際に、そのソリューションを作るのか買うのか選択することになります。

• 作る
  • オブザーバビリティツールを作ることはコア業務ではない
  • 自社リソースを使うだけならコストメリットあり
  • 社内のナレッジや文化をツールに反映できる
  • メンテナンスも考慮すること
• 買う
  • 有償製品
    • TCO メリット
    • Time To Value
  • オープンソース
    • ツールは無償
    • インフラコスト、学習コスト、運用コストを考慮
• 作ると買うの両方

オブザーバビリティの機能要件

オブザーバビリティデータに対するクエリは、できるだけ早く応答されるべきです。有用なデータを繰り返し反復しながら調査することが有用だからです。

すべてのテレメトリーデータはクエリ可能でなければなりません。

オブザーバビリティデータは本番環境のデバッグに使用されるため、問題が解決されたことを知る必要があります。

データストアは耐久性を信頼性を備えていなければなりません。

サンプリング

一定規模を超えるとすべてのテレメトリーデータの収集・処理・保存のコストは、メリットを超えます。
適切なサンプリングを行い、オーバーヘッドを削減しつつ、探索性を確保します。

• 一定確率サンプリング
  • 10回に1回を保存するなど
• 直近のリクエスト量に合わせる
• イベント内容に基づくサンプリング
  • エラーは成功より重要など

(吉井) 17章では様々なサンプリング手法とその実装が紹介されており、オブザーバビリティデータの改善に役立つと思います。

パイプラインによるテレメトリー管理

大量のテレメトリーデータを管理する方法としてのパイプラインです。

テレメトリーパイプラインの基本コンポーネントは以下です。

• レシーバー
  • ソースからデータを収集
• バッファ
  • 一時的なデータ置き場
  • AWS でいうと Kinesis
• プロセッサー
  • バッファからデータを取り出し変換
  • バッファに戻すことが多い
  • サンプリング、フィルタリング、リラベル、構造化への変換など
• エクスポーター
  • バッファからデータを取り出しデータストアに保管

(吉井) 18章では、大規模オブザーバビリティを扱ううえで重要なパイプラインが解説されています。 テレメトリーパイプラインを導入するメリットは多くあります。コストとのバランスを取りながらパイプライン導入を検討してみてはいかがでしょうか。

第Ⅴ部　オブザーバビリティの文化を拡大する

第Ⅴ部は、組織全体でオブザーバビリティを採用するための文化的なメカニズムの解説です。

オブザーバビリティの投資対効果

未知の未知に対処することがオブザーバビリティの核心です。
オブザーバビリティは4つの重要な方法で最終損益に影響を与えます。

• 収益の増加
  • 稼働時間とパフォーマンス向上
  • コード品質の向上
• インシデント対応の迅速化によるコスト削減
  • インシデントにかかる人件費削減
• インシデント回避によるコスト削減
  • 問題が重大化する前にその原因を発見
• 従業員の離職率低下によるコスト削減
  • 仕事の満足度向上、燃え尽きの回避、オンコール疲れの回避

(吉井) 19章は、オブザーバビリティを組織に採用したい管理職向けの内容です。

オブザーバビリティの利害関係者と協力者

オブザーバビリティは利害関係者の知識ギャップを埋めることが可能です。利害関係者を味方につけて支援しましょう。

• カスタマーサポートチーム
  • SLO ダッシュボードをひと目見て、顧客に影響を与える問題を把握
• カスタマーサクセスチーム
  • 製品使用状況の把握、使用パターンの分析
• 営業チーム
  • 見込み客が最も興味を持ち機能は何か
• 役員
  • ビジネスインパクトを最大化する方法を決定的に理解したい

オブザーバビリティ成熟度モデル

組織のオブザーバビリティに対するアウトカムを測定し、今後進むべきパスを示す手段として成熟度モデルの紹介です。

成熟度モデルは、組織における具体的で測定可能な目標を特定して定量化し、長期計画を推進するのに役立ちます。

(吉井) 書籍の著者の組織では独自に成熟度モデルを開発し運用しています。オブザーバビリティ採用の大きな助けになるはずです。書籍でご確認ください。

まとめ

システムの安定稼働はビジネスにおいて重要な要素です。安定稼働を実現するための手法の一つがオブザーバビリティです。
運用監視といったステージではなく、開発段階から取り入れるべきものがオブザーバビリティです。 従来のデバッグやモニタリングとの違いや利点を理解する最初に一歩になるのがこの書籍『オブザーバビリティ・エンジニアリング』です。

以上、吉井 亮 がお届けしました。